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TJ.S.C, 103 S REJECTION 

Claims 1, 3 4, 6, 8, 9, 1 1 and 13-24 were rejected under 35 U.S.C. as being unpatentable 
over Blinn, et al, (U.S, Patent No. 6,058,373). Claims 1, 3 4, 6, 8, 9, 1 1 and 1 3-24 were also 
rejected under 35 U.S.C as being unpatentable over Johnson, et al. (U.S. Patent No. 6,023, 683). 

Examiner in his responses has made some sweeping statements with which Applicants 
continue to respectfully disagree. Also, the Examiner failed to explain how either Blinn or 
Johnson could be split in two to produce Applicants 1 invention. As Applicants have stressed 
there are fundamental differences between what we claim and what is taught by Blinn or Johnson 
that prevents that from happening. What applicants provide is simply not the splitting apart 
portions of Blinn or Johnson. These differences appear in almost every claim. 

In order to convince the Examiner of this and to avoid an appeal* Applicants have 
produced a claim chart, which is appended to this request, for reconsideration as Exhibit 1 , which 
will explain, again, why these statements are inaccurate when close scrutiny is applied to the 
claims pending in this case. It also illustrates how applicant's invention relates to those claims 
and how different the Blinn et al. and Johnson et al. references are to what Applicants claim as 
their invention. If necessary, Applicants would like to meet with the Examiner to discuss the 
claim chart. 

So, Applicants will now refer to the claim chart of Exhibit to help the Examiner 
understand the fundamental differences between their invention and the art cited. 

Claim 1 

There are three primary elements in this system claim and, as indicated in the claim chart, 
the Blinn specification has no analog to either the a or c element and the Johnson reference 
neither a, b or c! Applicants don't disagree that Blinn is "electronic" and helps create and 
process orders. But Applicants are claiming neither. What Applicants claim, is a system that 
intercepts an already created order and performs activities on it prior to reaching the order 
process system. The only element arguably present in Blinn is a system to determine whether or 
not a part is to be back-ordered. Without arguing whether it is or isn% the check is performed 
inside the order processing system of Blinn after the order is received. So really, Blinn fails to 
teach any of the elements of Claim 1, much like the Johnson reference. 

Claim 3 

There are no functions in Blinn et al. that translate data from any format other than its 
format. So it does not teach a. Blinn does not determine whether an availability check is 
required, as in b. It has a basic format for performing that check after the sales order is within its 
system. As to element c, there is no facility in Blinn to create only a portion of the order within 
its system, once the order is submitted*. Johnson fails to teach anything about receiving sales 
order data , since it does not receive sales order data, so it does not possess elements a* Johnson 
does perform availability check of element b, but does not apply the means for "determining" 
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claimed by the current invention. Johnson resubmits an order to change it. It does not change it 
prior to submission to the order processing system. Johnson does not provide any teaching of 
element e. Thus, in addition to the elements of claim 1 on which claim 3 depends, neither Blinn 
nor Johnson teaches all the elements of claim 3, either alone or in combination. 

Claim 4 

As illustrated in Exhibit 1, neither Blinn nor Johnson teaches the workbench claim 4. 
Examiner must interpret claim 4 as applicants have defined it in their specification, consistent 
with 112, paragraph 6. So again, neither Blinn nor Johnson teaches all the elements of claim 4, 
let alone the claims on which it depends.. 

Claim 6 

As illustrated in Exhibit 1 , in element "a", Blinn does not provide a display of errors after 
in the manner of Applicant's invention. Johnson does not process orders at all, so does not have 
this facility. There are no means for displaying u error messages", as claimed in element b, in 
Blinn. Johnson does have a facility for displaying errors but, in the context of a requisition, not 
an order. Johnson provides no functionality for correcting orders, as provided in element c. So 
again, neither Blinn nor Johnson teaches all the elements of claim 6, let alone the claims on 
which it depends.. 

Claim 8 

As illustrated in Exhibit 1, element a is not taught at all in Johnson. Nor is element b 
taught anywhere in Johnson. There is nothing specified in Blinn regarding order rejection or 
what happens when an order item is rejected, and certainly not the means specified by 
Applicants, let alone the claims on which it depends. 

Claim 9 

As illustrated in Exhibit 1 , there is nothing in either Blinn or Johnson that provides a 
reject acknowledgment system, let alone the claims on which it depends. 

Claim 11 

As illustrated in Exhibit 1, there is nothing in either Blinn or Johnson that provides a 
means for updating, let alone the claims on which it depends. 

Claim 13 

As illustrated in Exhibit 1 , there is nothing in either Blinn or Johnson that provides a 
means for determining (element a) or a means for updating (element b) in either Blinn or 
Johnson, let alone any claims on which it depends. 
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Claim 14 

As illustrated in Exhibit 1, Blinn receives order requests from its own html formatted 
pages, not via an EDI format. Johnson mentions EDI for purchase orders placed on an EDI 
enabled customer, but not for requisitions which the Examiner has attempted to draw his 
analogies. 

Claim 15 

As illustrated in Exhibit 1 , neither Blinn nor Johnson links to an SAP system. 

As Exhibit 1 illustrates, even viewing every claim independently, neither Blinn nor 
Johnson fails to teach what is claimed by the Applicants. And, what is even more fundamental, 
there is no way either can alone, or in combination, provide any basis for Examiner's rejection, 
even if one subscribes to the proposition that Applicant's invention is the same as Blinn, but in 
unintegrated fonn. Additionally, there is nothing in Blinn or Johnson that hints that they could 
be. 

Claims 16 through 24 are method claims and media claims, with restrictions that appear 
in Exhibit 1 analogs for the systems claims already discussed. In working through the 
restrictions for those claims, Applicants will refer back to elements in the already discussed 
claims that refer to these restrictions. 

Claim 16 

Claim 16 has method steps, with the restrictions similar to those discussed in the Exhibit 
for Claim 1, elements a, b and c, plus the first element "a" of claim 3, referring to an availability. 
Referring to Exhibit 1 for claim 1 and element a of claim 3, it is clear that both Blinn and 
Johnson fail to teach the restrictions cited in the method steps of claim 1 6* For example, there is 
"no receiving of electronic sales orders electronically for pre-processing prior to being 
transmitted to the order processing system" is akin to element a of claim 1 . Translating the 
electron sales order is, fundamentally, element a of claim 3. The transmitting ... to an interface 
step is akin to element b of claim 1 and the transmitting to the order processing system is akin to 
element c of claim I. It is made clear by Exhibit 1 and the arguments made in discussing the 
elements of claim 1 and element a of claim 3, neither Blinn nor Johnson addresses what is 
claimed by 16. In fact, neither Blinn nor Johnson provides much in the way of teaching of any of 
these steps. 

Claim 17 

Referring to Exhibit 1, the discussion regarding the "business rules" step of this claim 
relative to Blinn and Johnson, appears in element e of claim 3. As illustrated, Johnson provides 
no teaching in this area and, if there is any teaching of this step, it occurs inside the order 
processing system, not at the stage after the order is submitted, but before it reaches the 
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processing system. The "determining of processing problems steps'* is discussed, with regard to 
element d, in claim 3. 

The discussion regarding the "if there are any problems" step appear in claim 6, element 
b, of Exhibit 1. Since claim 17 depends on claim 16, which is clearly patentable, claim 17 is 
also patentable.. 

Claim IS 

The discussion regarding enabling a user to correct orders, appears in Exhibit 1 , when 
discussing element 6(c). Johnson does not provide such a system at alL And, although Blinn 
does provide an ability, it is within the order processing system itself So, there is no 
'transmitting to the order processing" as stated in the second step of claim 1 8. Since claim 1 8 
depends on allowable claim 17, it is also in condition for allowance. 

Claim 19 

The discussion regarding the steps of "rejecting" and "updating" appears in Exhibit 1, 
when discussing claims 9 and 11 As mentioned previously, neither Blinn nor Johnson provides 
any teaching of either of these steps. Thus, claim 1 9 is an allowable claim and, since it depends 
on allowable claim 16, is further allowable. 

Claim 20 

The discussion regarding the EDI format appears in Exhibit 1 , when discussing claim 14. 
As indicated there, Blinn does not apply EDI to its orders. Johnson mentions EDI for purchase 
orders placed on an EDI enabled customer, but not for requisitions which the Examiner has 
attempted to draw his analogies. For these reasons, claim 20 is allowable, and for the additional 
reason that it depends on allowable claim 16. 

Claim 21, 22, 23,24 

Claim 21, 22, 23, and 24 are media claims incorporating the same steps as claim 16, 17, 
18 and 19, respectively . Therefore, the references to Exhibit 1 and the arguments made in claim 
16, 17, 18, and 19 equally apply to claim 21, 22, 23, and 24, respectively. 

General: 

The reason Applicants have presented their arguments in form of a chart is that it allows 
the Examiner to compare the claims, in terms of the lexicography used by the Applicants, 
paragraph 6 of 35 U.S.C. 1 12, and to provide focus to what is actually claimed in terms of the 
fact that Johnson et al. and Blinn et aL really specify different parts of an overall fulfillment 
system. Examiner has seemingly focused on the commonality that must exist with regards to the 
data and has glossed over the differences. 
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Applicants have read Nerwin v. Erlichman, 168 USPQ 177, 179, and find it not on point 
In fact, it adds support to Applicant's arguments. The citation to the Supreme Court case therein 
states that the grate in question "contains all the elements of the Beckwith grate, except for being 
in two pieces," (Emphasis mine.) The exhibit that Applicants provided herein illustrates that not 
all the elements are in either of the references. In fact "multiple elements" of multiple 
independent and independent claims do not appear in either of the references. Finally the case 
itself is for the proposition that one could claim an integral structure as consisting of various 
element for the purposes of an interference count 

Examiner additionally refers to MPEP Section 2144.04 in an attempt to counter 
Applicants arguments* It is just as inapposite* The case appearing therein for making separable 
is a lipstick holder and the difference was between a press fit and a removable structure, 
something that almost anyone could find obvious and with all the structural elements present and 
something that can easily be explained by almost anyone. The applicants on page 6 of their last 
office action asked the Examiner to specify how Blinn et ah or Johnson et al. could be split into 
two systems. All that the Examiner could proffer is case law that really is not on point. Exhibit 
1 clearly illustrates why this is the only answer the Examiner can provide. It can't be done. You 
can't split in two something that already lacks the essential elements of Applicant's invention. 

Finally, in reference to Examiner's citation of In re Bond, 1 5 USPQ2d 1 566 (Fed. Cir. 
1 990) Examiner notes that "a reference must show the claimed elements arranged in the 
manner of the claims, but not in the identical words as used in the claims in order to be 
anticipatory. 19 (Emphasis mine) As Exhibit l clearly illustrates again and again, for those 
elements that may appear in the reference, they were arranged (in term of system or process flow) 
in a much differ manner than either of the references. 

Accordingly, Applicants respectfully submit that the Examiner has failed to establish a 
prima facie case of obviousness and failed to explain how the two references he cites can be 
somehow split into two to produce Applicant's claimed invention. Therefore, all claims pending 
should be moved to allowance. 

As Applicants indicated above, we respectfully request a meeting with the Examiner to 
help him understand the differences between the invention and the prior art as it appears in 
Exhibit!. 
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CONCLUSION 



In view of the foregoing remarks, Applicants submit that all of the claims are patentably 
distinct from the prior art of record and are in condition for allowance. The Examiner is 
respectfully requested to pass the above application to issue. The Examiner is invited to contact 
the undersigned at the telephone number listed below, if needed. Charge any deficiencies and 
credit any overpayment of fees to Deposit Account No. 09-0456. 



IBM Corporation 
1000 River Street 
Essex Junction, VT 05452 
Telephone: 802-769-4457 
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EXHIBIT 1 



CLAIM 


OUR SPECIFICATION 


BLINN 
SPECIFICATION 


JOHNSON 
SPECIFICATION 


1 (Amended) A 
System for pre- 
processing orders 
before they are 
transmitted to an 
order processing 
system, comprising: 








a. An order interceptor 
receiving and pre- 
processing 
electronic sales 
order data prior to 
transmitting to the 
order processing 
system. 


The order interceptor 
receives the order 
request after the order 
has been submitted by 
the customer and 
before being posted to 
an order processing 
system. This allows 
the supplier to manage 
and configure the order 
before the physical 
order is created. Once 
a physical order is 
created, some 
attributes to the order 
can not be changed. 
The order interceptor 
gives the supplier 
functionality to manage 
the order request freely 
based on business 
rules. 


Blinn et al. provides a 
dynamic front end 
interface to the 
customer. Once the 
customer accepts and 
submits the order, the 
order is posted into the 
Blinn order processor 
and begins flowing 
through the 'order 
pipeline 1 within the 
Order Processing 
module (Fig. 3, 126). 
There is no means for 
an order manager to 
modify the order 
request prior to the 
creation of the order in 
the order processing 
system. 


Johnson et al. 
describes an electronic 
sourcing system that 
provides the user with 
the capability of 
searching multiple 
vendor product 
catalogs and using 
information from that 
catalog to generate a 
requisition containing 
entries from that 
product catalog. Once 
a requisition has been 
inventory sou reed and 
accepted by a CSR, it 
can be converted into 
one or more purchase 
orders to a supplier. It 
does not however 
provide a supplier with 
the ability to manage 
the order request 
before it is loaded as a 
sales order. 
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b- An interface system 
receiving the 
electronic sales 
order data from the 
order interceptor end 
performing an 
availability check, 
wherein the 
availability check 
determines portions 
of the electronic 
sales order data that 
can be satisfied. 


Once an order request 
has been submitted by 
the customer and the 
order interceptor has 
received the order 
request based on 
business rules 
configured for a 
customer/material, an 
Availability to Promise 
forecast/inventory 
system can be invoked 
to determine if a 
material is available for 
a given quantity on a 
given date. It allows the 
customer service 
representative to 
manage inventory 
allocations to orders 
and prioritize that 
inventory before the 
order enters the 'order 
pipeline'. 


The inventory stage 
(Fig. 3, 384. Note text 
2950) is the closest 
resemblance to an 
availability check. This 
inventory check is 
based on existing 
inventory stocks and 
sets the flag on the 
order to indicate 
whether there is 
sufficient inventory or rf 
the item needs to be 
backordered. There 
are no functions for 
interfacing with a 
forecasting/inventory 
management function 
using business rules to 
determine product 
allocation. 


Inventory data loaded 
on the users local 
system is referenced 
when a requisition is 
configured. The RIMS 
inventory sourcing 
system is accessed 
when building the 
requisition to determine 
if there is a local supply 
of inventory available 
and its location. There 
are no linkages to an 
outside suppliers 
inventory. There are 
no functions for 
interfacing with a 
forecasting/inventory 
management function 
using business rules to 
determine product 
allocation. 


c. Means for 
transmitting at least 
a portion of the 
electronic sales 
order data to the 
order processing 

processing. 


If it is determined 
during order request 
review that some lines 
of an order are invalid, 
can not be fulfilled, or 
for any reason not to be 

pntfirad Into fhp 
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order system, these 
lines can be rejected 
and only the approved 
order lines are created 
in the sales order 
system. 


There is no function in 
Blinn et al. that sends a 
subset of an order to its 
order processing 
system. When the 
customer submits the 

nrrtAr tfiP r*nmnlptp 

order is created and 
processed via the 
'order pipeline'. Once 
an order is created in 
the pipeline, all lines on 
that order are 
maintained and 
processed. 


Once a requisition is 
submitted within 
Johnson et al. t the 
submitted requisition 
would have to be 
revised and 

rp^iihiTtift#»ri 

1 COUUI 1 1 IUEU. 


3. (Twice amended) 
The system of claim 
1 , wherein the order 
interceptor 
comprises: 
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a. means for translating 
the electronic sales 
order data to an 
internal format of the 
order interceptor. 


The order interceptor 
receives the electronic 
sales order data in an 
EDI format or any 
predetermined record 
format and translates 
the ESO into its own 
internal format for 
processing. 


There are no functions 
in Blinn et al. that 
translate data from any 
format other than its 
own front end order 
generator. This 
prevents its order 
processor to receive 
orders from any other 
media/file formats. 


Johnson et al. is not a 
sales order system and 
therefore does not 
receive sales order 
data- 


b. means for 
determining if an 
availability check is 
required. 


For some materials, it 
may not be necessary 
to perform an 
availability check. This 
is configured at a 
customer/material 
level. If the availability 
check is required, the 
order interceptor will 
interface with a third 
party planning/forecast 
system to determine 
and manage product 
availability. 


Blinn et al. has a baste 
format to check 
inventory and assign 
that inventory to a sales 
order AFTER the sales 
order has been created 
within its system. This 
inventory request is 
configurable at a 
system level and not a 
customer/material 
level. 


Johnson et al. is not a 
sales order system and 
therefore does not 
receive sales order 
data. However, it 
does perform inventory 
availability checking for 
inventory managed 
within itself and returns 
to the requisition the 
location and quantities 
available. If the item Is 
not found in its locally 
managed inventory, an 
external purchase 
order is generated. If 
the item is found 
locally, then a purchase 
order is placed on the 
local distributor. 


c. means for 

transmitting at least 
a portion of the 
electronic sales 
order data. 


When the order 
interceptor receives a 
sales order request, it 
can send a subset of 
the sales order request 
to the order processing 
system. The order 
Interceptor can also 
split a sales order 
request into multiple 
sales orders to send to 
the order processing 
system. This allows 
orders to be directed to 
multiple sales areas 
within the order 
processing system. 


Once an order request 
is submitted by the 
customer to the order 
processing engine, the 
supplier must manage 
all items on the order. 
There is no facility to 
create only a subset of 
the order within the 
order processing 
system. This creates 
redundant and non- 
essential data within 
the order processing 
system. 


A requisition can be 
modified after it is 
submitted by altering 
the requisition and 
resubmitting the 
purchase order if 
necessary. It does not 
provide the ability to 
change a purchase 
order once it is 
submitted. 
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d. means for 
determining if there 
are any processing 
problems associated 
with the electronic 
sales order data. 


While processing a 
sales order request the 
order interceptor 
performs edits and 
audits on the sales 
order request to 
determine if all 
necessary criteria 
specific for the order 
processing system are 
complete. If not, the 
order is directed to the 
order interceptor 
workbench where it can 
be managed by the 
customer service 
representative. 


Blinn et al. performs 
edits/audits on the 
sales order request 
prior to submission by 
the customer. When 
the order is submitted, 
any edits/audits 
performed by the order 
processing system are 
performed at this stage, 
therefore creating an 
invalid order that 
potentially must be 
resubmitted. 


When building the 
requisition, Johnson et 
al. gathers all pertinent 
information from the 
product catalog entries 
it is processing. This 
information is then 
loaded into the 
purchase requisition. If 
it Is determined that the 
data is not accurate, 
messages are 
displayed while building 
the purchase 
requisition and are 
manually addressed by 
the user. 


e. means for 
processing the 
electronic sales 
order data in 
accordance with 
business rules. 


While processing a 
sales order request, the 
order interceptor allows 
a supplier to configure 
how a request is 
managed using 
business rules. These 
business rules allow 
certain functions to be 
automated if specified 
criteria are satisfied. 


Blinn et al. can perform 
some business rules 
logic during the front 
end generation of the 
sales order request and 
also during the 
processing of the sales 
order in the sales order 
engine. However, it 
can not apply business 
rules before the order 
is generated after it has 
been submitted by the 

it is based on key- 
ksy/value pairs, it does 
not provide customer 
tier functionality to 
provide different 
functionality based on 
the customer 
configuration. 


Johnson et al. is driven 
primarily from the 
product catalogs and 
its associated data. 
There are no 
configurable business 
rules within the process 
defined in this patent 
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4. The system of claim 
1 , further comprising 
a workbench 
receiving electronic 
sales order data that 
contains errors or is 
incomplete. 

• 


Sales order requests 
that have failed 
edit/audits or just need 
to be reviewed prior to 
creation in a sales 
order system are sent 
to an order interceptor 
workbench. The 
Workbench provides a 
customer purchase 
order view of the sales 
order request that 
looks, feels, and 
behaves like actual 
order entry screens. 
This facility allows the 
customer service 
representatives to 
correct and manage 
orders from a 
consolidated 
workbench before they 
are sent to an order 
processing system. 
The order requests 
also are passed 
through phases in 
processing so that 
different roles within 
processing orders can 
manage the sales order 
request prior to entry 
into the order system. 


Blinn et aL does not 
have a consolidated 
workbench to process 
order requests or even 
orders. It uses a 
blackboard concept 
where the user can 
updates key/key-value 
relationships for data 
during each stage of 
the process. This 
allows data flexibility as 
an order goes through 
the process, but a user 
whose responsibilities 
span multiple areas wilt 
still have to enter each 
area of the order 
processing system to 
enter those specific 
values. 


Johnson et al. does not 
have a workbench to 
process sales order 
requests. The only 
area where errors are 
corrected is within the 
purchase requisition 
definition maintenance 
menus. 


6. (Twice amended) 
The system of claim 
4, wherein the 
workbench 
comprises: 
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a. means for displaying 
electronic sales 
order data that 
contains errors or is 
incomplete. 


The order interceptor 
can receive incomplete 
or erroneous order 
request data submitted 
by the customer without 
causing errors. It 
provides the facility and 
architecture to clean 
and complete the data 
and then feed it into an 
order processing 
system. 


Blinn et at. does not 
receive data from other 
front end order 
processing systems. It 
performs its 
edits/audits while the 
customer inputs the 
order. It then loads the 
data into the order 
processing system 
where the order is 
processed and errors 
corrected. 


Johnson et al. does not 
process sales orders. 
It generates purchase 
orders based on 
requisitions. Therefore 
it has no functionality in 
this area. 


b. means for displaying 
error messages 
associated with the 
electronic sales 
order data of step a. 


The order interceptor 
workbench displays all 
messages associated 
with an order request 
and presents all order 
request details for the 
user to process. 


Blinn et al. contains an 
order processor stage 
called the 'Order Check 
Stage 1 . In this stage, 
there are two optional 
components called 
OrderValidate 
(validates at an order 
level) and 
Order! temValidate 
(validates at an order 
item level). These 
components will only 
ensure that certain 
fields are filled in and 
that the fields contain 
the correct data type for 
the field (e.g. date is a 
valid date, string 
contains string data, 
etc). The patent text 
does not specify how 
errors are processed 
once detected. 


For purchase 
requisitions that contain 
errors, error messages 
are displayed, 
optionally printed, and 
then manually 
corrected if possible. 


c. means for correcting, 
editing, and updating 
at least one 
database containing 
electronic sales 
order data. 


The workbench 
provides the ability to 
correct any errors, 
manage committed 
order request 
dates/quantities with 
delivery plants, and 
allows updating the 
sales order request 
directly on the 
database prior to entry 
into the order process 
system. 


Blinn et al. provides the 
ability to correct, edit, 
and update the order 
database with order 
and order item 
information from within 
its own order 
processing system, but 
not before the order is 
generated on its order 
processing system. 


Johnson et al. does 
process sales orders. 
It generates purchase 
orders based on 
requisitions. Therefore 
it has no functionality in 
this area. 
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8. {Once Amended) 
The system of claim 
6, wherein the 
workbench further 
comprises: 








a. means for displaying 
the status of the 
electronic sales 
order data. 


The order interceptor 
gives the ability to view 

the status of order 
requests as it passes 
through the stages of 
pre-processing. It can 
show what stage the 
order request is in 
along with any 
conditions that must be 
satisfied to make it a 
complete and accurate 
order when posted to 
the order processing 
system. It does this via 
a consolidated screen 
with links to each order 
stage processing 
specific data. 


Blinn et al. displays the 
status of the order as it 
flows through its order 
processing stages. As 
the order progressing 
through each stage, the 
order manager can 
update each key/key- 
value pair based on 
each stages data 
requirements. It does 
not have a consolidated 
view of the order status 
from a single interface. 


Johnson et al. does not 
specify in the patent 
text any means for 
displaying the status of 
a purchase requisition 
and obviously not sales 
orders. 


b. means for 
determining if the 
configuration rules 

are satisfied* 


When an order request 
is received, the order 
interceptor will 
configure the order 
request in accordance 
with business rules and 
determine if the order if 
configuration rules for 
the specific customer 
are satisfied. 


Order requests 
generated via Blinn et 
al. can copy information 
regarding the customer 
from customer 
configuration and 
attach it to the order 
using key-vaiue pairs 
during the order 
initialization stage. 
However, it these 
configurations do not 
alter the way an order 
is processed in its 
order processing 
system. 


Johnson et al. does not 
specify in the patent 
text any means for 
using configuration 
rules to alter 
processing 
requirements. 
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c. means for indicating 
to the order 
interceptor that at 
least a portion of the 
electronic order data 
is rejected. 


If an order manager 
determines that certain 
items of an order 
request are not valid for 
processing or are 
unable to be satisfied, 
these lines or the entire 
order can be rejected 
and an 

acknowledgment sent 
to the front end order 
system. 


There is not any text 
regarding order 
rejection or what 
happens if an order or 
order item is rejected 
during order 
processing. 


Individual lines of a 
requisition can be 
maintained through the 
requisition 

maintenance screens. 
Lines can be 
added/deleted/modified 
and the requisition will 
be re-processed if 
necessary. 


9. The system of claim 
1, further comprising 
a reject 

acknowledgment 
system receiving an 
indication from the 
order interceptor that 
at least a portion of 
the electronic sales 
order data has been 
rejected. 


When the order 
interceptor determines 
that certain lines or the 
entire order is rejected 
for any business 
reason, it can invoke a 
reject acknowledgment 
system that manages 
rejected items or orders 
and sending notices to 
the customer of such 
rejections with the 
reason/reasons. 


There is not any text 
regarding order 
rejection or what 
happens if an order or 
order item is rejected 
during order 
processing. 


Johnson et al. does not 
mention any reject 
acknowledgment 
function within the 
patent text 


11. (Amended) The 
system of claim 9, 
wherein the reject 
acknowledgment 
system comprises: 








a. means for updating 
at least one 
database to indicate 
the portions of the 
electronic order data 
that have been 
rejected. 


The reject 
acknowledgment 
system updates the 
order request database 
and other audit 
database tables with 
the order request 
rejection history of what 
was rejected, why, and 
when the rejection 
acknowledgment was 
sent to the customer. 


There is not any text 
regarding order 
rejection or what 
happens if an order or 
order item is rejected 
during order 
processing. 


Johnson et al. does not 
mention any reject 
acknowledgment 
function within the 
patent text. 
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13. (Amended) The 
system of claim 11, 
wherein the reject 
acknowledgment 
system further 
comprises: 








a. means for 
determining if the 
electronic sales 
order data was 
received via a 
transmission from 
the World Wide 

WcD. 


The reject 
acknowledgment 
system can determine 
the source of the order 
request and send 
reject 

acknowledgments back 
to me oraer request 
system in an EDI 
format or notification to 
a front-end Web based 
system. 


Since there is not an 
order rejection 
component with Blinn 
et al., there is not any 
text regarding order 
rejection, what happens 
if an order or order item 
is rejected during order 
processing, or where 
the order data was 
received. 


Johnson et al. does not 
mention any reject 
acknowledgment 
function within the 
patent text 


b. means for updating 
the at least one 
database in either as 
ESO format or an 
SAP format. 


The reject 
acknowledgment 
system can reject the 
order request or lines 
of an order request and 
maintain the database 
tables in either an 
internal format or an 
SAP specific format. 


Since there is not an 
order rejection 
component with Blinn 
et aJ., there is not any 
text regarding order 
rejection or what 
happens if an order or 
order item is rejected 
during order 
processing. 


Johnson et al. does not 
mention any reject 
acknowledg ment 
function within the 
patent text 


14. The system of 
claim 1, wherein the 
order interceptor 
receives the 
electronic sales 
order data in a 
standard Electronic 
Data Interchange 
(EDI) format. 


The order interceptor 
has the capability to 
receive order requests 
via an EDI format 
which is primarily used 
for business to 
business system 
communication. 


Blinn et al. receives 
order requests from its 
own front-end Web 
based html formatted 
pages. 


Johnson et at. does not 
use EDI except for 
purchase orders placed 
on an EDI enabled 
customer. Purchase 
requisitions are entered 
and maintained 
manually. 
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15. "me order 
interceptor system of 
claim 1. wherein the 
system in an SAP 
system. 


The order interceptor 
svstem can be utilized 
within an SAP system 
environment and use 
SAP as the order 
management system 
and/or order request 
system. 


Blinn et at. is itself an 

system with a direct link 
with its front-end order 
request module. 


Johnson et al does not 
uuijze an oroer 
processing system nor 
any function of SAP. It 
is based on purchase 
requisitions generated 
manually using one or 
more item catalogs. 
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